Release 10.1A: OpenEdge Development:
Progress Dynamics Administration

DCU interface

The DCU is driven from one window that contains several component sections. Every aspect of the user interface can be customized, but the main DCU window must remain the same size. The components displayed on each page are defined in the deployment’s DCU driver file.

Figure 5–2 shows the sections of the main DCU window.

Figure 5–2: DCU interface

The DCU’s component frames are as follows:

Bitmap frame — Contains a bitmap that is specified in the DCU driver file.
Page frame — Contains a Progress 4GL frame that has been derived from the DCU’s template frame. The pages that are displayed in this frame are derived from DCU driver file.
Button frame — Contains the buttons that are defined within the DCU driver file for each page of the DCU wizard.

Each page displayed by the DCU is a frame that has been defined using the template src/install/intmplframe.w. There is little code inside the frame definition, because the behavior for all the controls is defined inside the DCU’s API and XML files. When a page is displayed, the actions defined in the XML file are associated with the appropriate event on the controls. Then, any necessary processing is activated.

Users can even customize attributes of the individual controls that appear in the frame from within XML files by associating the attribute with the object’s variable name. During the process of displaying the page, the DCU API determines the name of each control and associates attributes with the control as necessary.

While you can build new pages for the DCU wizard using the template, src/install/intmplframe.w, the existing pages can be adapted for most of your needs. If an existing page has an object that you do no need, you can hide it by adding a <Hidden> node to the corresponding XML control description.

The DCU has two trigger procedures that work with objects on the Wizard pages. The trigger code for a button’s CHOOSE event runs the btnChoose API, as follows:

DO:   RUN btnChoose IN THIS-PROCEDURE. END.

For any other event for any object, there is a single API, eventProc. It takes two parameters, the name of the UI event and the name of the object the event. The following example shows the code for LEAVE event on a fill-in field:

DO:   RUN eventProc IN THIS-PROCEDURE ("LEAVE":U,"{&SELF-NAME}":U) NO-ERROR.   IF ERROR-STATUS:ERROR THEN     RETURN NO-APPLY. END.

To code any UI event on a page, you would add this code to the object’s trigger section, substituting the appropriate parameter values. The existing pages are stored in the src\dynamics\install\obj directory.

Table 5–1 describes the existing frames.

Table 5–1: DCU standard pages and their objects 

Page	Description	Objects
indbconn	Page for gathering database connection information.	edComment (Editor) lCreate (Toggle-box) lBuild (Toggle-box) fiPath1 (Fill-in) buPath1 (Button) fiPath2 (Fill-in) buPath2 (Button) fiConnect (Fill-in) edConnect (Editor)
indbinfo	This page is no longer used by the DCU.	edComment (Editor) lICFDB (Toggle-box) lRVDB (Toggle-box) fiPath4 (Fill-in) buPath4 (Button)
inpath	Page for gathering paths.	edComment (Editor) fiPath1 (Fill-in) buPath1 (Button) fiPath2 (Fill-in) buPath2 (Button) fiPath3 (Fill-in) buPath3 (Button) fiPath4 (Fill-in) buPath4 (Button)
inselect	Page with editor and a selection list.	edComment (Editor) seList (Selection-list)
insite	Page for gathering site and sequence information.	edComment (Editor) fiNumber (Fill-in) fiSiteSeq1 (Fill-in) fiSiteSeq2 (Fill-in) fiSessionID (Fill-in)
instatus	Page with two editors.	edComment (Editor) edStatus (Editor)
inwelcome	Page with one editor.	edEditor (Editor)